Packet interfaces are usually implemented based on either a parallel interface (e.g. OIF SPI4.2 interface 16 bit at 622 to 800 Mbps), or serial interfaces (e.g. XAUI 4 lane at 3.125 Gbps). An overview of the XAUI interface vs. the SPI4.2 interface is shown in FIG. 1, with the XAUI interface generally indicated at 10, and the SPI4.2 interface generally indicated at 12.
SPI4.2 is a wide (16 signal bits in both receive and transmit), source-synchronous (a clock signal is supplied by the transmitter) parallel interface that provides up to 256 channels of communication and independent flow control for each channel.
While SPI4.2 offer many advantages (channelization, programmable burst size, per-channel back-pressures, etc), it is a very wide interface (more than 80 I/Os). SPI4.2 suffers also from a reach limitation. In particular, it is difficult to implement longer than about a dozen inches.
XAUI is a narrow (4 signal bits in both receive and transmit) interface based on serializer-deserializer (serdes) technology that lacks any concept of channels. Serdes-based interfaces are capable of longer range than source-synchronous parallel interfaces, and can be routed across board interconnects and system backplanes.
Referring again to FIG. 1, the XAUI interface includes XAUI analog functionality generally indicated at 14 consisting of XAUI TX and XAUI RX, and the XGXS sub-layer function 16 which converts between packets in the XGMII protocol and the four lane format required by the XAUI TX and XAUI RX 14. The XGXS sub-layer defines the system-side data interface, jitter testing operations, lane deskew.
The XAUI Interface generates four channels of serial data (differential) at 3.125 Gbps per channel. The reverse applies in the receive direction. The XGMII interface is as defined in the IEEE Draft P802.3ae Clause 46. The XGXS and XAUI functions are as defined in the IEEE 802.3ae Clause 47, Clause 48 and Annex 48A.
The XGMII protocol defines an 8 byte preamble for Ethernet Frames (consisting of one start character, six preamble bytes and one start of frame delimiter—FB 55 55 55 55 55 55 D5), a minimum of 64 and a maximum of 1518 payload data bytes (including CRC), one end of frame delimiter (FD) followed by a minimum of 12 interframe idle characters (07). Referring now to FIG. 2, this information is formatted into four 8 bit lanes 24. There is also one control character 26 per lane as shown in FIG. 2.
The control character is a 4 bit value determined by the XGMII coding. For example an Idle character /I/ has a control value of ‘1’. Each bit corresponds to a lane: i.e. bit 0 indicates whether lane zero is a control character or a data character, bit 1 indicates this for lane 1, and so on.
Referring again to FIG. 1, in the transmit direction, the XGXS 16 takes XGMII format data and control which is then encoded using the standard 8 bit to 10 bit encoding scheme (8b/10b). The result is serialized into four data streams 20 at 3.125 Gbps. A number of test patterns can be selected as encoded data for testing purposes.
In the receive direction, four data streams 22 at 3.125 Gbps have the clock and data recovered and converted to four streams of 10 bit parallel data. These are word and lane aligned followed by decoding using the reverse of the 8b/10b scheme. Verifiers can verify the received test patterns for testing purposes.